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Many  systems  execute  untrusted  programs  in  virtual  machines  (VMs)  to  mediate  their  ac¬ 
cess  to  system  resources.  Sun  introduced  the  Java  VM  in  1995,  primarily  intended  as  a  light¬ 
weight  platform  for  executing  untrusted  code  inside  web  pages.  More  recently,  Microsoft 
developed  the  .NET  platform  with  similar  goals.  Both  platforms  share  many  design  and 
implementation  properties,  but  there  are  key  differences  between  Java  and  .NET  that 
have  an  impact  on  their  security.  This  paper  examines  how  .NET'S  design  avoids  vulnera¬ 
bilities  and  limitations  discovered  in  Java  and  discusses  lessons  learned  (and  missed)  from 
experience  with  Java  security. 
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1.  Introduction 

Java  and  .NET  are  both  platforms  for  executing  untrusted  pro¬ 
grams  with  security  restrictions.  Although  they  share  similar 
goals  and  their  designs  are  similar  in  most  respects,  there  ap¬ 
pear  to  be  significant  differences  in  the  likelihood  of  security 
vulnerabilities  in  the  two  platforms. 

Fig.  1  shows  the  number  of  major  security  vulnerabilities 
reported  for  each  platform.  As  of  December  2005,  the  Common 
Vulnerabilities  and  Exposures  (CVE)  database  contains  150 
entries  concerning  Java  vulnerabilities  (Mitre  Corporation, 
Common  Vulnerabilities),  38  of  which  we  classify  as  major 
Java  platform  security  vulnerabilities  (we  do  not  include  appli¬ 
cation-specific  bugs  unrelated  to  the  VM  itself).  The  remaining 
vulnerabilities  included  in  Fig.  1  but  not  in  the  CVE  are  from 
Sun  (Sun  Microsystems,  2002)  (9  vulnerabilities)  and  McGraw 
and  Felten  (1999)  (5  vulnerabilities).  The  contrast  with  the 


.NET  platform,  in  which  no  major  security  vulnerabilities 
have  yet  been  found,  appears  striking.  This  paper  considers 
whether  or  not  the  difference  in  the  number  of  security  vul¬ 
nerabilities  found  in  the  two  platforms  stems  from  fundamen¬ 
tal  differences  in  their  designs. 

Table  1  summarizes  Java  security  vulnerabilities  reported 
in  the  past  10  years.  Hopwood  (1996),  Princeton’s  Secure  Inter¬ 
net  Programming  team  (Dean  et  al.,  1996;  Wallach  et  al.,  1997; 
Wallach  and  Felten,  1998)  and  McGraw  and  Felten  (1999)  iden¬ 
tified  several  vulnerabilities  in  early  Java  implementations. 
The  rest  are  those  documented  in  Sun’s  chronology  (Sun 
Microsystems,  2002;  Sun  Microsystems  Sun  Alert)  and  the 
CVE  database  (Mitre  Corporation,  Common  Vulnerabilities). 

By  contrast,  no  security  vulnerabilities  in  the  .NET  virtual 
machine  platform  have  been  reported  to  date.  The  most  widely 
publicized  security  issue  in  .NET  was  W32. Donut,  a  virus  that 
took  control  of  the  executable  before  the  .NET  runtime  had 
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Fig.  1  -  Major  security  vulnerabilities  reported.  The  value 
plotted  is  the  cumulative  number  of  major  security  vulner¬ 
abilities  reported  in  each  platform  since  the  first  official  re¬ 
lease  (Java  1.0  in  January  1996  (Sun  Microsystems,  Java); 
.NET  1.0  in  January  2002  (Microsoft  Corporation,  Technology 
Overview)). 


control  (Szor).  Since  the  vulnerability  occurs  before  the  .NET 
runtime  takes  control,  we  consider  this  a  problem  with  the 
way  the  operating  system  transfers  control  to  .NET  and  not 
with  the  .NET  platform.  Eight  other  security  issues  that  have 
been  identified  in  the  .NET  are  listed  in  Microsoft’s  Knowledge 
Base  (Farkas)  and  the  CVE  database  (Mitre  Corporation,  Com¬ 
mon  Vulnerabilities),  but  none  of  them  are  platform  security 
vulnerabilities  by  the  standard  we  use  in  this  paper.  Appendix 
A  explains  these  issues  and  why  we  do  not  count  them. 

There  are  many  possible  explanations  for  the  .NET  plat¬ 
form’s  apparent  lack  of  security  vulnerabilities.  One  possibil¬ 
ity  is  that  .NET  is  a  less  desirable  platform  for  attackers  to 
compromise  than  Java  so  it  has  not  received  the  scrutiny  nec¬ 
essary  to  reveal  vulnerabilities.  This  is  unlikely,  however, 
since  the  .NET  framework  is  now  provided  as  a  Windows 
update.  Since  Windows  has  over  90%  of  the  desktop  market 
with  a  large  number  of  machines  using  .NET,  the  .NET  plat¬ 
form  presents  an  attractive  target. 

Another  possibility  is  that  more  vulnerabilities  have  been 
found  in  Java  implementations  because  there  are  several 


different  Java  VM  implementations  whereas  .NET’s  number 
is  from  Microsoft’s  sole  implementation.  From  the  available 
information,  the  one  implementation  that  did  have  many  of 
its  own  unique  vulnerabilities  was  Microsoft’s  Java  implemen¬ 
tation,  and  this  is  largely  due,  in  part,  to  10  vulnerabilities 
reported  in  November  2002  by  Pynnonen.  As  early  as  March 
1996,  both  Microsoft  and  Netscape  had  licensed  Java,  two 
months  after  the  1.0  release  date  (Sun  Microsystems,  Java). 
As  Java  licensees,  both  Microsoft  and  Netscape  implementa¬ 
tions  are  based  on  the  Sun  implementation  (Sun  Microsys¬ 
tems,  2002)  so  much  of  the  code  and  design  are  shared 
across  the  three  implementations.  The  first  9  reported  Java 
vulnerabilities  did  affect  all  three  implementations,  including 
the  first  5  of  13  total  verifier  vulnerabilities.  Although  popular 
open  source  .NET  platform  implementations  exist,  such  as 
Mono,  and  dotGNU,  neither  has  fully  implemented  code  ac¬ 
cess  security  to  enable  the  execution  of  partially  trusted  code. 

Another  possibility  is  that  .NET  just  avoided  the  specific 
security  vulnerabilities  that  were  already  known  because  of  pre¬ 
vious  experience  with  Java.  This  may  be  true  in  a  few  cases,  but 
in  general  it  is  not  the  case.  There  are  enough  differences  be¬ 
tween  the  platforms  that  most  security  vulnerabilities  would 
not  have  a  direct  analog.  Further,  vulnerabilities  continue  to 
be  found  in  new  versions  of  Java  even  after  .NET’s  release. 

In  this  paper  we  explore  the  more  optimistic  hypothesis 
that  .NET’s  design  is  fundamentally  more  secure  than  Java’s, 
and  in  particular,  that  it  benefits  from  following  general  secu¬ 
rity  principles  that  have  been  learned  and  reinforced  from 
experience  with  Java.  The  general  lessons  to  be  learned  from 
experience  with  Java  are  not  new.  Most  of  them  go  back  at 
least  to  Saltzer  and  Schroeder’s  (1973)  classic  paper,  and 
none  should  be  surprising  to  security  analysts.  In  particular: 
economy  of  mechanism,  least  privilege,  and  fail-safe  defaults 
are  design  principles  that  enhance  security,  but  can  often  con¬ 
flict  with  other  goals  including  usability  and  complexity. 
Other  lists  of  security  principles,  including  Viega  and 
McGraw’s  (2001),  include  similar  properties  such  as  defense 
in  depth  and  securing  the  weakest  link.  Viega  and  McGraw 
emphasize  that  security  principles  should  be  followed  within 
an  application’s  context  and  following  these  universal  secu¬ 
rity  principles  allows  a  programmer  to  weigh  different  design 


Table  1  -  Java  security  vulnerabilities 

Category 

Count 

Instances 

API  bugs 

12 

CVE-2000-0676,  CVE-2000-0711,  CVE-2000-0563,  CVE-2002-0865, 

CVE-2002-0866,  CVE-2002-1260,  CVE-2002-1293,  CVE-2002-1290, 

CVE-2002-1288,  CVE-2002-0979,  CVE-2005-3905,  CVE-2005-3906 

Verification 

13 

Sun  Chronology  (4),  McGraw  and  Felten  (2),  CVE- 1999-0766,  CVE-1999-0141, 
CVE-1999-0440,  CVE-2000-0327,  CVE-2002-0076,  CVE-2003-0111,  CVE-2004-2627 

Class  loading 

8 

Sun  Chronology  (5),  CVE-2002-1287,  CVE-2003-0896,a  CVE-2004-0723 

Other  or  unknown 

3 

CVE-2001-1008,  CVE-2002-1325,  CVE-2005-3907 

Missing  policy  checks 

3 

CVE-1999-0142,  CVE-1999-1262,  McGraw  and  Felten  (1) 

Configuration 

5 

CVE-2000-0162,  CVE-2002-0058,  CVE-2005-0471,  McGraw  and  Felten  (2) 

DoS  attacks  (crash) 

4 

CVE-2002-0867,  CVE-2002-1289,  CVE-2003-0525,  CVE-2004-0651 

DoS  attacks  (consumption) 

4 

CVE-2002-1292,  CVE-2004-2540,  CVE-2005-3583,  CVE-2004-1503 

Vulnerabilities  reported  in  Java  platform  in  CVE  database  (Mitre 
Sun  Microsystems,  Sun  Alert),  and  McGraw  and  Felten  (1999). 

Corporation,  Common  Vulnerabilities),  Sun’s  web  site  (Sun  Microsystems,  2002; 

Vulnerabilities  reported  in  more  than  one  source  were  counted  once. 

a  Revealed  under  keyword  search  for  JVM  vulnerabilities  instead  of  Java  vulnerabilities. 
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trade-offs  while  preparing  for  unknown  attacks  that  may  not 
fit  past  attack  patterns  (Viega  and  McGraw,  2001).  The  con¬ 
crete  experience  with  Java  shows  how  failure  to  apply  these 
well  known  principles  has  lead  to  vulnerabilities  in  a  particu¬ 
lar,  security-critical  system. 

Previous  work,  including  Pilipchuk’s  article,  has  compared 
security  mechanisms  and  features  in  Java  and  .NET  from  an  op¬ 
erational  perspective.  In  this  paper,  we  consider  how  they  differ 
from  the  perspective  of  what  has  and  has  not  been  learned  from 
experience  with  Java.  The  primary  contributions  of  this  paper 
are  as  follows:  (1)  an  illustration  of  how  the  history  of  Java  secu¬ 
rity  vulnerabilities  reveals  failures  to  follow  established  security 
principles;  (2)  an  identification  of  how  .NET’s  security  mecha¬ 
nisms  have  addressed  the  vulnerabilities  and  limitations  of 
Java;  and  (3)  a  discussion  on  how  differences  in  the  design  of 
.NET  and  Java  are  likely  to  impact  their  security  properties. 

Next,  we  provide  an  overview  of  both  platforms.  Section  3 
describes  low-level  code  safety  highlighting  the  importance  of 
simplicity.  Section  4  examines  policy  definition  and  permis¬ 
sions  emphasizing  the  principles  of  fail-safe  defaults,  least 
privilege,  and  complete  mediation.  Associating  policies  with 
code  according  to  the  code  attributes  is  discussed  in  Section  5. 
Next,  Section  6  describes  how  the  JVM  and  CLR  enforce  poli¬ 
cies  on  executions  evaluating  them  in  their  application  of 
the  principles  of  least  privilege,  fail-safe  defaults,  and  com¬ 
plete  mediation.  Section  7  discusses  the  shortcomings  of 
both  platforms  with  respect  to  psychological  acceptability. 


2.  Platform  overview 

Both  Java  and  .NET  use  a  virtual  machine  to  enforce  policies 
on  executing  programs  as  depicted  in  Fig.  2.  The  term  Java  is 
used  to  refer  to  both  a  high-level  programming  language  and 
a  platform.  We  use  Java  to  refer  to  the  platform  consisting  of 
everything  used  to  execute  the  Java  class  containing  Java  vir¬ 
tual  machine  language  code  (JVML,  also  known  as  “Java  bytec¬ 
odes”)  in  the  left  part  of  Fig.  1  except  the  operating  system  and 
the  protected  resource.  A  Java  archive  (JAR)  file  encapsulates 
Java  classes  and  may  also  contain  other  resources  such  as 
a  digital  signature  or  pictures.  Java  was  designed  primarily 
to  provide  a  trusted  environment  for  executing  small  pro¬ 
grams  embedded  in  web  pages  known  as  applets. 


Java  .NET 


The  .NET  platform  includes  the  .NET  part  of  the  figure 
involved  in  executing  an  assembly  except  for  the  operating 
system  and  the  protected  resource.  A  .NET  assembly,  analo¬ 
gous  to  Java’s  JAR  file,  is  an  executable  or  dynamically  linked 
library  containing  Microsoft  intermediate  language  instruc¬ 
tions  (MSIL),  some  metadata  about  the  assembly,  and  some 
optional  resources.  .NET  differentiates  between  managed 
(safe)  and  unmanaged  (unsafe)  codes.  Since  a  security  policy 
cannot  be  enforced  on  unmanaged  code,  we  only  consider 
managed  code. 

Both  Java  and  .NET  have  large  trusted  computing  bases 
(TCBs)  allowing  many  possible  points  of  failure.  The  TCB  in¬ 
cludes  everything  in  Fig.  1  except  for  the  external  untrusted 
program  (the  Java  class  or  .NET  assembly).  In  Java,  a  flaw  in 
the  bytecode  verifier,  class  loader,  JVM  or  underlying  operat¬ 
ing  system  can  be  exploited  to  violate  security  properties. 
With  .NET,  a  flaw  in  the  policy  manager,  class  loader,  JIT  ver¬ 
ifier,  CLR,  or  underlying  operating  system  can  be  exploited  to 
violate  security  properties.  The  size  of  the  TCB  makes  it  infea¬ 
sible  to  make  formal  claims  about  the  overall  security  of  either 
platform;  instead,  we  can  analyze  individual  components 
using  the  assumption  that  other  components  (in  particular, 
the  underlying  operating  system)  behave  correctly. 

The  JVML  or  MSIL  code  may  be  generated  by  a  compiler 
from  source  code  written  in  a  high-level  program  such  as 
Java  or  C#,  but  these  files  can  be  created  in  other  ways. 
Although  high-level  programming  languages  may  provide 
certain  security  properties,  there  is  no  way  to  ensure  that 
the  delivered  JVML  or  MSIL  code  was  generated  from  source 
code  in  a  particular  language  with  a  trusted  compiler.  Hence, 
the  only  security  provided  against  untrusted  code  is  what  the 
platform  provides.  This  paper  does  not  consider  the  relative 
merits  of  the  Java  and  C#  programming  languages  but  only 
compares  the  security  properties  of  the  two  execution 
platforms. 

Since  the  Java  platform  was  introduced  in  1995,  Java’s  se¬ 
curity  model  has  evolved  to  incorporate  additional  security 
mechanisms  including  code  signing  and  increasingly  flexible 
policies.  When  specific  implementation  issues  are  considered, 
we  address  the  current  standard  implementations  of  each 
platform:  the  Java  2  Software  Development  Kit  1.4.2  and  the 
.NET  Framework  1.1. 

Both  Java  and  .NET  use  a  combination  of  static  analysis  and 
dynamic  checking  to  enforce  policies  on  executing  programs. 
The  bytecode  verifier  in  Java  and  the  just-in-time  (JIT)  verifier 
in  .NET  statically  verify  some  low-level  code  properties  neces¬ 
sary  (but  not  sufficient)  for  type  safety,  memory  safety  and 
control-flow  safety  before  allowing  programs  to  execute. 
Other  properties  must  be  checked  dynamically  to  ensure 
low-level  code  safety.  Section  3  describes  the  principle  of  sim¬ 
plicity  in  low-level  code  safety  properties.  Six  of  the  30  Java 
platform  security  vulnerabilities  in  the  Common  Vulnerabil¬ 
ities  and  Exposures  database  (Mitre  Corporation,  Common 
Vulnerabilities),  and  6  of  the  earlier  vulnerabilities  (McGraw 
and  Felten,  1999;  Sun  Microsystems,  2002)  are  directly  attrib¬ 
uted  to  flaws  in  implementations  of  the  Java  bytecode  verifier. 
Programs  that  pass  the  verifier  are  executed  in  the  Java  virtual 
machine  (JVM)  or  .NET  Common  Language  Runtime  (CLR). 
Both  virtual  machines  use  a  reference  monitor  to  mediate  ac¬ 
cess  to  protected  system  resources. 


Fig.  2  -  Architecture  overview. 
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3.  Low-level  code  safety 

Low-level  code  safety  comprises  the  properties  of  code  that 
make  it  type,  memory,  and  control-flow  safe.  Without  these 
properties,  applications  could  circumvent  nearly  all  high-level 
security  mechanisms  (Yellin,  1995).  The  primary  lesson  learnt 
from  Java’s  experience  with  low-level  code  safety  goes  back  to 
one  of  the  earliest  security  principles:  keep  things  simple. 

Type  safety  ensures  that  objects  of  a  given  type  will  be  used 
in  a  way  that  is  appropriate  for  that  type.  In  particular,  type 
safety  prevents  a  non-pointer  from  being  dereferenced  to  ac¬ 
cess  memory.  Without  type  safety,  a  program  could  construct 
an  integer  value  that  corresponds  to  a  target  address,  and  then 
use  it  as  a  pointer  to  reference  an  arbitrary  location  in  mem¬ 
ory.  Memory  safety  ensures  that  a  program  cannot  access 
memory  outside  of  properly  allocated  objects.  Buffer  overflow 
attacks  violate  memory  safety  by  overwriting  other  data  by 
writing  beyond  the  allocated  storage  (AlephOne,  1996).  Con¬ 
trol  safety  ensures  that  all  jumps  are  to  valid  addresses.  With¬ 
out  control  safety,  a  program  could  jump  directly  to  system 
code  fragments  or  injected  code,  thereby  bypassing  security 
checks. 

Java  and  .NET  achieve  low-level  code  safety  through  static 
verification  and  runtime  checks.  In  typical  Java  implementa¬ 
tions,  static  verification  is  done  by  the  Java  bytecode  verifier 
at  load  time.  An  entire  class  is  verified  before  it  is  executed 
in  the  virtual  machine.  In  .NET,  parts  of  the  verification  are 
done  as  part  of  the  JIT  compilation.  All  code  must  pass  the  ver¬ 
ifier,  however,  before  it  is  permitted  to  execute. 

3.1.  Verification 

The  first  step  in  the  verification  process  is  the  validation  of  the 
file  format  of  the  code  (ECMA  International,  2002;  Lindholm 
and  Yellin,  1999).  The  file  is  checked  according  to  the  Java  class 
file  or  .NET  PE/COFF  file  specifications  (Lindholm  and  Yellin, 
1999;  Microsoft  Corporation,  Microsoft  Portable  Executable). 
Following  the  verification  of  the  file  format,  the  verifier  also 
checks  some  static  rules  to  ensure  that  the  objects,  methods, 
and  classes  are  well  formed. 

Next,  the  verifier  simulates  each  instruction  along  each  po¬ 
tential  execution  path  to  check  for  type  and  other  violations. 
Since  JVML  and  MSIL  are  stack-based  languages,  executions 
are  simulated  by  modeling  the  state  of  the  stack  while  track¬ 
ing  information  about  each  instruction  to  help  ensure  low- 
level  code  safety.  Verification  fails  if  a  type  violation  could 
occur,  or  a  stack  operation  could  cause  underflow  or  overflow. 
In  addition,  control-flow  safety  is  ensured  by  checking  that  all 
branch  instructions  target  valid  locations. 

The  general  problem  of  verifying  type  safety  is  undecidable 
(Pierce,  1992),  so  certain  assumptions  must  be  made  to  make 
verification  tractable.  Both  verifiers  are  conservative:  if  a  pro¬ 
gram  passes  verification  it  is  guaranteed  to  satisfy  prescribed 
safety  properties,  however,  programs  exist  that  are  type  safe 
but  fail  verification.  A  more  sophisticated  verifier  could  accept 
more  of  the  safe  programs  (still  rejecting  all  unsafe  programs), 
but  increasing  the  complexity  of  the  verifier  is  likely  to  intro¬ 
duce  additional  vulnerabilities. 


Code  passing  the  verifier  is  permitted  to  run  in  the  virtual 
machine,  but  additional  runtime  checks  are  needed  that  could 
not  be  checked  statically.  Runtime  checks  are  required  to  en¬ 
sure  that  array  stores  and  fetches  are  within  the  allocated 
bounds,  elements  stored  into  array  have  the  correct  type 
(because  of  covariant  typing  of  arrays  in  both  JVML  and  MSIL 
this  cannot  be  checked  statically  (Cook,  1989)),  and  down 
cast  objects  are  of  the  correct  type. 

A  bug  in  the  Java  bytecode  verifier  or  Microsoft’s  JIT  verifier 
can  be  exploited  by  a  hostile  program  to  circumvent  all  secu¬ 
rity  measures,  so  complexity  in  the  verifier  should  be  avoided 
whenever  possible. 

The  JVML  and  MSIL  verifiers  are  both  relatively  small,  but 
complex,  programs.  Sun’s  1.4.2  verifier  (Sun  Microsystems, 
Java  2  SDK)  is  4077  lines  of  code  (not  including  code  for  check¬ 
ing  the  file  format).  For  .NET,  we  examined  Rotor,  the  shared 
source  code  that  is  a  beta  version  of  Microsoft’s  implementa¬ 
tion  of  the  ECMA  CLI  standard  (Stutz).  The  JIT  verifier  in  the 
production  .NET  release  is  either  very  similar  or  identical  to 
the  Rotor  verifier  (Lewin,  2004).  Rotor’s  integrated  verifier 
and  JIT  compiler  total  about  9400  lines,  roughly  4300  of  which 
are  needed  for  verification. 

3.2.  Instruction  sets 

Since  the  verifier’s  complexity  is  directly  tied  to  the  instruc¬ 
tion  set  of  the  virtual  machine,  examining  the  instruction 
sets  provides  some  measure  of  the  verifier’s  complexity. 
Each  platform  uses  about  200  opcodes,  but  some  important 
differences  in  their  instruction  sets  impact  on  the  complexity 
of  their  verifiers.  This  section  considers  the  differences  be¬ 
tween  the  JVML  and  MSIL  instruction  sets  from  the  perspec¬ 
tive  of  how  complex  it  is  to  verify  low-level  code  safety 
properties. 

Table  2  summarizes  the  instruction  sets  for  each  platform. 
One  obvious  difference  between  the  instruction  sets  is  that 
JVML  has  separate  versions  of  instructions  for  each  type, 
whereas  .NET  uses  a  single  instruction  to  perform  the  same 
operation  on  different  types.  For  example,  Java  has  four  differ¬ 
ent  add  instructions  depending  on  the  type  of  the  data  (iadd 
adds  integers,  fadd  adds  floats,  etc.)  where  .NET  has  one  in¬ 
struction  that  works  on  different  types.  Using  generic  instruc¬ 
tions  to  perform  an  operation  with  multiple  types  instead  of 
just  two  types  makes  verification  slightly  more  difficult,  but 
means  that  .NET  has  more  instruction  opcodes  available  for 
other  purposes.  .NET  uses  some  of  these  instructions  to  pro¬ 
vide  overflow  and  unsigned  versions  of  the  arithmetic  opera¬ 
tions.  The  overflow  versions  of  arithmetic  operations  throw 
exceptions  if  the  calculation  overflows,  enabling  applications 
to  better  handle  overflows  and  avoid  security  vulnerabilities 
related  to  arithmetic  overflows  (such  as  the  Snort  TCP  Stream 
Reassembly  Integer  Overflow  Vulnerability  reported  in  Core 
Security  Technologies  Advisory). 

3.2.1.  Function  calls 

Complex,  multi-purpose  instructions  further  increase  verifi¬ 
cation  complexity.  For  example,  the  invokespecial  instruction 
in  JVML  serves  three  purposes:  calling  a  superclass  method, 
invoking  a  private  method,  and  invoking  an  initialization 
method.  The  multiple  uses  of  this  instruction  make  it  difficult 
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Table  2  -  Instruction  sets  comparison 

Type 

JVML 

MSIL 

Number 

Examples 

Number 

Examples 

arithmetic 

36 

iadd,  fadd,  ladd,  iand 

21 

add,  add_ovf,  xor 

stack 

11 

pop,  dup2,  swap 

2 

pop,  dup 

compare 

21 

ifeq,  if null,  if_icmpeq 

29 

ceq,  beq,  brfalse 

load 

51 

Ldc,  iload,  iaload 

65 

Ldarg,  ldftn,  ldstr 

store 

33 

Istore,  lstore_l,  castore 

27 

Starg,  stloc_s,  stelem_R8 

conversions 

15 

i2f ,  d2i ,  12d 

33 

conv_i2,  conv_ovf_u8,  conv_u2 

method  calls 

4 

invokevirtual,  invokestatic, 
invokespecial,  invokeinterf ace 

3 

callvirt,  call,  calli 

object  creation 

4 

new,  newarrary,  anewarray, 

mult ianewar ray 

2 

newobj ,  newarr 

exceptions 

3 

athrow,  jsr,  ret 

5 

leave, leave_s,  rethrow,  endfilter, 
endf inally 

to  verify  correctly.  Sun’s  verifier  uses  260  lines  to  verify  the 
invokespecial  instruction  (counting  major  methods  used  for 
verification).  A  2001  verifier  bug  involving  the  Invokespecial 
instruction  (Sun  Microsystems,  Sun  Security)  affected  many 
implementations  of  the  JVM,  and  could  be  exploited  to  violate 
type  safety  (Last  Stage  of  Delirium  Research  Group). 

.NET  has  two  main  instructions  for  calling  methods:  call 
and  callvirt  (another  MSIL  calling  instruction,  calli,  is  used 
for  calling  functions  indirectly  through  a  pointer  to  native 
code).  The  call  instruction  is  similar  to  Java’s  Invokespecial 
and  invokestatic  instructions.  The  callvirt  instruction  is 
similar  to  Java’s  invokeinterf ace  and  invokevirtual  instruc¬ 
tions.  The  main  difference  between  the  call  and  callvirt  in¬ 
structions  is  how  the  target  address  is  computed.  The  address 
of  a  call  is  known  at  link-time  while  callvirt  determines  the 
method  to  call  based  on  the  runtime  type  of  the  calling  object. 
Combining  Java’s  four  different  calling  instructions  into  two 
instructions  may  make  it  easier  for  a  compiler  writer  (Meijer 
and  Gough),  but  given  Java’s  history  of  trouble  it  may  have 
been  better  to  have  several  single-purpose  call  instructions 
rather  than  a  few  instructions  with  multiple  functions.  The 
call  and  callvirt  instructions  each  have  their  own  method 
for  JIT  compilation  and  verification  totaling  approximately 
200  lines  in  the  Rotor  implementation. 

To  efficiently  support  tail  recursion,  the  MSIL  call  instruc¬ 
tions  may  also  be  preceded  by  a  tail  prefix  which  is  treated 
as  a  special  case  by  the  verifier  (ECMA  International,  2002). 
The  tail  prefix  reuses  the  same  activation  record  on  the  stack 
instead  of  creating  a  new  record  every  time  a  call  is  made. 
About  250  extra  lines  are  required  for  verification  and  compila¬ 
tion  of  the  tail  prefix  including  the  extra  lines  needed  to  deal 
with  call,  calli,  and  callvirt.  It  is  too  soon  to  judge  whether 
the  performance  advantages  of  supporting  tail  outweigh  the 
additional  security  risks  associated  with  the  added  complexity. 

3.2.2.  Object  creation 

Sometimes  a  complex  single  instruction  is  better  than  using 
many  separate  instructions.  For  example,  a  Java  program  cre¬ 
ates  a  new  object  by  using  new  to  allocate  memory  for  the  new 
object,  dup  to  place  an  additional  reference  to  the  newly  cre¬ 
ated  object  on  the  stack,  and  then  invokespecial  to  call  the 
object’s  initializing  constructor.  After  returning  from  the  con¬ 
structor,  a  reference  to  the  (now  initialized)  object  is  on  top  of 


the  stack  because  of  dup.  In  MSIL,  the  single  newobj  instruction 
calls  a  constructor,  creating  and  initializing  a  new  object  in 
one  step.  This  sacrifices  flexibility,  but  verification  of  newobj 
is  much  easier  than  Java’s  sequence  of  instructions  since  the 
verifier  knows  that  the  object  is  initialized  as  soon  the  instruc¬ 
tion  is  executed. 

A  Java  verifier  must  check  whether  any  new  object  is  ini¬ 
tialized  before  use  (Leroy,  2001).  Java’s  verifier  has  difficulty 
with  two  areas  in  object  creation.  In  cases  where  the  new, 
dup  and  invokespecial  instructions  are  separated  by  instruc¬ 
tions,  this  can  pose  problems  for  the  verifier.  The  second  prob¬ 
lematic  area  is  the  complexity  of  the  invokespecial 
instruction.  Microsoft  and  Netscape’s  Java  verifiers  have 
both  had  vulnerabilities  relating  to  improper  object  initializa¬ 
tion.  The  Microsoft  verifier  bug  involved  calling  a  constructor 
within  an  exception  handler  inside  a  child  class  (Last  Stage  of 
Delirium  Research  Group).  Once  the  code  called  the  construc¬ 
tor  from  inside  the  child  class,  the  parent  class  constructor 
would  be  called  to  create  a  ClassLoader  object,  but  the  child 
class  had  not  been  given  permission  to  instantiate  a  class 
loader.  The  resulting  exception  was  caught  by  the  exception 
handler  in  the  constructor  of  the  child  class,  and  the  initializa¬ 
tion  was  incorrectly  assumed  to  have  completed. 

3.2.3.  Exception  handling 

Java’s  exception  handling  instructions  impose  additional 
complexity  compared  to  MSIL’s  simpler  approach.  The  JVML 
instruction  jsr  is  used  to  implement  the  Java  programming 
language  try-finally  construct  that  transfers  execution  to  a 
finally  block  (Lindholm  and  Yellin,  1999)  and  is  one  of  the 
most  complex  instructions  to  verify.  To  jump  to  a  finally 
block,  control  transfers  to  an  offset  from  the  address  of  the 
jsr  instruction,  and  the  return  address  of  the  next  instruction 
after  the  jsr  instruction  is  pushed  onto  the  stack.  The  main 
problem  is  the  use  of  the  operand  stack  to  store  the  return 
address  since  this  makes  an  attractive  target  for  an  attacker 
who  may  try  to  insert  a  different  address  while  fooling  the 
verifier.  With  the  return  address  on  the  operand  stack, 
more  difficulty  exists  in  a  finally  block’s  verification  in  the 
multiple  ways  one  could  execute  a  finally  block:  a  jsr  called 
after  execution  of  the  try  clause,  a  jsr  used  upon  a  break/ 
continue  within  the  try  clause,  or  a  return  executed  within 
the  try  block. 
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Several  vulnerabilities  have  been  found  in  Java  verifiers 
due  to  the  complexity  of  the  jsr  instruction.  One  relating  to 
subroutines  in  exception  handling  was  found  in  1999  in  the 
Microsoft  JVM  (Last  Stage  of  Delirium  Research  Group).  To  ex¬ 
ploit  this  flaw,  two  return  addresses  are  placed  on  top  of  the 
stack  using  different  jsr  instructions.  Next,  a  swap  instruction 
is  executed.  The  verifier  failed  to  account  for  the  change  of 
return  addresses  on  the  stack  (ignoring  the  swap  since  the 
return  addresses  are  of  the  same  type).  The  switched  return 
address  is  used  by  the  ret  instruction  to  return  to  the  instruc¬ 
tion  that  is  now  referenced  by  the  address.  The  verifier  con¬ 
tinues  to  verify  the  method  as  if  the  swap  had  not  executed, 
thus  breaking  type  safety. 

.NET  avoids  the  complexity  associated  with  Java’s  jsr 
instruction  by  providing  a  simpler  instruction.  The  leave  in¬ 
struction  used  to  exit  a  try  or  catch  clause  clears  the  operand 
stack  and  uses  information  stored  in  an  exception  handling 
clause  for  control  flow. 

Recently,  Sun  has  announced  a  radical  redesign  of  its  byte¬ 
code  verifier.  The  new  verifier  that  is  part  of  the  new  Java  SE 
Mustang  release  will  have  two  very  important  simplifications: 
the  separation  of  the  type  inferencing  process  and  the  re¬ 
moval  of  any  code  that  generates  a  jsr  or  ret  instruction  (Sun 
Microsystems,  JSR  202;  Sun  Microsystems,  New  Java  SE). 
The  verifier  can  now  use  type  information  embedded  in  the 
class  file  represented  as  a  code  attribute  instead  of  having  to 
infer  the  type  information.  To  ease  this  transition  to  the 
new  verifier,  the  verification  process  reverts  to  using  the  old 
verifier  if  a  class  file  is  not  recognized  as  a  newer  version 
50.0  class  file  (Sun  Microsystems,  New  Java  SE). 

Disabling  the  JVM  from  running  older  class  files  can  be 
done  by  passing  a  flag  to  the  JVM.  This  design  can  break  back¬ 
ward  compatibility  for  the  benefit  of  the  simplicity  of  verifica¬ 
tion,  but  users  should  have  more  confidence  in  the  security  of 
the  Java  verifier.  This  is  an  encouraging  step  towards  simplic¬ 
ity,  in  contrast  to  nearly  all  of  the  modifications  to  the  Java 
platform  since  1995  that  increased  complexity. 

3.2.4.  Summary 

We  tested  .NET  to  check  that  the  verifier  was  behaving  correctly 
according  to  the  ECMA  specification  and  attempted  to  carry  out 
exploits  that  have  previously  worked  on  the  Java  verifier,  but 
were  unable  to  construct  any  successful  exploits.  Of  course, 
this  does  not  mean  that  there  are  no  exploitable  bugs  in  the 
.NET  verifier,  but  it  is  encouraging  that  no  verifier  bugs  have 
been  reported  to  date.  .NET’s  designers  avoided  many  of  the  pit- 
falls  in  early  Java  implementations  benefiting  from  Java’s  his¬ 
tory  of  problems  with  exception  handling,  creating  objects, 
and  calling  methods.  The  MSIL  instruction  set  design  simplifies 
the  verification  process  by  avoiding  instructions  similar  to  the 
most  complex  instructions  to  verify  in  JVML. 


4.  Defining  policies 

Low-level  code  safety  mechanisms  prevent  hostile  applets 
from  circumventing  the  high-level  code  safety  mechanisms, 
but  security  depends  on  high-level  mechanisms  to  enforce 
a  policy  on  program  executions.  A  policy  specifies  what 


actions  code  may  perform.  If  a  program  attempts  an  action 
contrary  to  the  policy,  a  security  exception  is  raised. 

4.1.  Permissions 

The  amount  of  control  possible  over  system  resources  depends 
on  the  available  permissions.  Except  for  those  permissions  that 
are  platform  specific,  Java  and  .NET  provide  similar  permis¬ 
sions  for  controlling  access  to  the  file  system,  network,  display, 
system  properties  and  clipboard  (Microsoft  Corporation,  Secu¬ 
rity  Briefs;  Sun  Microsystems,  Permissions).  The  permissions 
provided  by  each  platform  are  summarized  in  Table  3. 

The  platforms  differ  in  which  resources  are  protected  by  per¬ 
missions,  and  in  the  granularity  of  control  over  specific 
operations  and  resources  the  available  permissions  provide.  In 
general,  .NET  and  Java  protect  the  same  set  of  resources  with 
permissions,  except  for  platform-specific  resources.  For  in¬ 
stance,  Java  must  provide  permissions  that  protect  some 
resources  that  are  not  exposed  in  .NET  including  the  Security- 
Manager  and  AccessControlContext  (see  Section  6.2).  Although 
.NET  has  a  registry  permission  to  protect  the  Windows  registry, 
Java  does  not  expose  this  resource  through  their  API  by  default. 
Similarly,  Java  has  an  AudioPermission  for  restricting  access  to 
audio  system  resources,  but  .NET’s  API  provides  no  access  to 
audio  resource.  Microsoft’s  DirectX  9.0  SDK  provides  access 
to  audio  resources,  and  adds  the  SoundPermission  to  control 
access  to  those  resources. 

In  general,  .NET  provides  permissions  with  finer  granularity 
of  control.  For  example,  both  platforms  provide  permissions  to 
restrict  access  to  the  file  system.  But,  whereas  in  Java  the  same 
permission  controls  deleting,  writing  to,  and  appending  to  files, 
in  .NET  it  is  possible  to  provide  just  append  access  to  a  file. 

Table  3  reveals  that  both  platforms  suffer  from  the  lack  of  a 
systematic  design  in  their  permissions.  Many  of  these  permis¬ 
sions  are  based  on  protecting  methods  provided  by  the  plat¬ 
form  API,  rather  than  protecting  security-critical  resources. 
For  example,  Java’s  SQLPermission  allows  a  program  to  set  the 
logging  stream  that  may  contain  private  SQL  data;  it  is  checked 
before  setLogWriter  methods  in  several  classes.  Java’s  AWTPer- 
mission. createRobot  permission  protects  j ava . awt . Robot  ob¬ 
jects  that  allow  the  creation  of  low-level  mouse  and  keyboard 
events.  .NET’s  Perf  ormanceCounterPermission  protects  diagnos¬ 
tic  information  exposed  by  the  API.  These  permissions  do  not 
correspond  well  to  security  properties  a  user  could  relate  to, 
but  rather  correspond  to  dangerous  API  methods. 

Designing  permissions  around  API  methods  rather  than 
security-critical  resources  is  dangerous  since  it  means  grant¬ 
ing  a  permission  may  provide  unexpected  capabilities.  For  ex¬ 
ample,  Java’s  Ref  lectPermission  indirectly  allows  a  program  to 
access  private  methods  and  fields;  effectively,  this  allows 
a  program  to  circumvent  other  security  checks  and  is  equiva¬ 
lent  to  granting  most  other  permissions.  .NET  provides  a  sim¬ 
ilar  ReflectionPermission,  but  allows  a  finer  granularity  of 
control  over  what  can  be  accessed.  Other  permissions  pro¬ 
vided  by  Java  that  effectively  grant  code  arbitrary  access 
include  FilePermission.  execute  (which  allows  a  program  to 
execute  a  system  command)  and  SecurityPermission .  setPolicy 
(which  allows  a  program  to  change  the  security  policy). 

Knowing  the  resulting  policy  after  granting  certain  permis¬ 
sions  is  an  area  of  difficulty  common  to  both  architectures.  A 
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Table  3  -  Permissions  summary  (Meijer  and  Gough;  .NET  Framework  Developer’s 

Guide) 

Resource 

Restricted  operations 

Java  permissions 

.NET  permissions 

File  system 

Read/write/execute/delete  files 

FilePermission 

FilelOPermission,  SecurityPermission 

Append  access  information  on 

No  separate  permissions 

FilelOPermissionAccess  (Append, 

path  itself 

(append  =  write) 

PathDiscovery) 

Access  data  in  current  directory 
from  executing  program 

Can  read  any  file  in  current 
directory  or  sub-directory  of 
current  directory 

IsolatedStoragePermission 

Network 

Accept/connect/listen/resolve  a 
host  at  an  optional  port  range 

SocketPermission 

SocketPermission 

Display 

Show  an  applet-created  window 
without  warning,  restrict  access  to 
event  queue 

AWTPermission 

Events  handled  differently  without 
special  permissions 

Controlling  different  properties  of  a 
window  (e.g.,  setting  caption,  hiding 
cursor) 

Not  provided 

UlPermission . Window 

Reflection 

Use  of  reflection 

Ref lectPermission 

Ref lectionPermission 

Reflection  on  visible  or  invisible 

Level  of  control  not  provided 

Ref lectionPermission,  different  flag 

members  of  a  type 

(all  or  nothing) 

values  control  the  level  of  use 

System  clipboard 

Read/write  clipboard  (all  or  nothing) 

AWTPermission 

UlPermission . Clipboard 

Read  clipboard  (write  unrestricted) 

Level  of  control  not  provided 
(all  or  nothing) 

UlPermission . Clipboard  (OwnClipboard) 

Threading 

Control  threads 

Runt imePermiss ion 

SecurityPermission 

Control  any  thread,  code’s  own  threads, 

RuntimePermission,  different 

Threadpool  provides  safety  through 

control  a  group  of  threads 

target  values 

control  level  of  privileges 

implementation 

Database 

Set  the  logging  stream  of  SQL  actions 

SQLPermission 

Logging  can  be  configured  through 
registry  or  provided  tools  (Meier  et  al.) 

Allow  blank  passwords  for  a  database 

Specific  database  API  not  included  OdbcPermission,  OleDbPermission, 

user,  access  databases 

by  default 

OraclePermission,  SqlClientPermission 

Printer 

Print 

RuntimePermission 

Print ingPermission 

Printing  to  any  printer  (default  only)  and 
through  restricted  print  dialog  boxes 

All  or  nothing  restriction  by 
RuntimePermission 

Print ingPermission 

Platform  specific 

Read/write/delete  registry  keys/values 

Resource  not  exposed  (no 
permission  needed) 

RegistryPermission 

developer  may  not  understand  that  granting  file  execute  or  re¬ 
flection  permissions  to  any  code  that  asks  for  it  is  essentially 
the  same  as  fully  trusting  the  code.  An  attacker  also  has  an  ad¬ 
ditional  method  of  attack  to  compromise  a  system  if  a  permis¬ 
sion  can  give  higher  privileges  in  a  different  way. 

Neither  platform  supports  complete  mediation:  only  ac¬ 
tions  associated  with  an  associated  predefined  permission 
are  checked  and  many  resources  (for  example,  allocating 
memory)  have  no  associated  permission.  Further,  there  is  no 
support  to  restrict  the  amount  of  a  resource  that  is  consumed, 
so  many  denial-of-service  attacks  are  possible  without  cir¬ 
cumventing  the  security  policy.  These  limitations  are  serious 
(LaDue),  but  more  complete  mediation  is  possible  through  the 
reference  monitoring  framework  only  by  significantly  reduc¬ 
ing  performance.  Richer  policy  expression  and  efficient  en¬ 
forcement  is  an  active  research  area  (Erlingsson,  2003;  Evans 
and  Twyman,  1999;  Walker,  2000). 

4.2.  Policies 

Policies  associate  sets  of  permissions  with  executions.  For  se¬ 
curity,  policies  should  follow  the  principle  of  least  privilege 
and  fail-safe  defaults,  however,  these  principles  often  conflict 
with  convenience  and  are  not  always  followed. 

In  Java,  policies  are  defined  by  specifying  the  permissions 
granted  in  a  policy  file  based  on  properties  of  an  execution: 


the  origin  of  the  code,  the  digital  code  signers  (if  any),  and  the 
principal  executing  the  code.  Java’s  policies  are  also  affected 
by  a  system- wide  properties  file,  j  ava .  security,  which  specifies 
paths  to  other  policy  files,  a  source  of  randomness  for  the  ran¬ 
dom  number  generator,  and  other  important  properties. 

A  Java  policy  file  contains  a  list  of  grant  entries.  Each  entry 
specifies  a  context  that  determines  when  the  grant  applies 
and  lists  a  set  of  granted  permissions  in  that  context.  The  con¬ 
text  may  specify  the  code  signers  (a  list  of  names,  all  of  whom 
signed  the  code  for  the  context  to  apply),  the  code  origin  (code 
base  URL),  and  one  or  more  principals  (on  whose  behalf  the 
code  is  executing).  If  no  principals  are  listed,  the  context  ap¬ 
plies  to  all  principals. 

Java  is  installed  with  one  system-wide  policy  file,  but  a  user 
can  augment  this  policy  with  her/his  own  policy  file.  The 
granted  permission  set  is  the  union  of  the  permissions 
granted  in  all  the  policy  files.  This  is  dangerous  since  it  means 
more  permissions  are  granted  than  those  that  appear  in  the 
user’s  policy  file.  Further,  it  means  a  user  can  make  the  policy 
less  restrictive  than  the  system  policy,  but  cannot  make  the 
policy  more  restrictive.  Java  users  may  not  exclude  permis¬ 
sions  a  system  administrator  allows  unless  they  are  able  to 
edit  java. security,  the  Policy  implementation,  or  the  policy 
file  granting  the  unwanted  permissions. 

.NET  provides  policy  definition  mechanisms  that  overcome 
these  limitations  by  providing  flexible,  multi-level  policies, 
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but  at  the  cost  of  greater  complexity.  A  .NET  policy  is  specified 
by  a  group  of  policy  levels:  Enterprise  (intended  for  the  system 
administrator),  Machine  (machine  administrator),  User,  and 
Application  Domain  (AppDomain).  The  permissions  granted  to 
an  assembly  are  the  intersection  of  the  permissions  granted 
at  the  four  policy  levels.  .NET’s  policies  grant  permissions 
based  on  evidences  within  an  assembly  (see  Section  5.2).  The 
AppDomain  policy  is  created  at  runtime,  and  there  is  no  associ¬ 
ated  configuration  file  for  this  policy  level.  If  no  AppDomain 
exists  at  runtime,  then  the  policy  is  the  intersection  of  the 
Enterprise,  Machine,  and  User  policy  levels.  .NET’S  policy  levels 
are  similar  to  Java  having  a  system-wide  policy  file  and  a  user 
policy  file,  however,  they  are  much  more  flexible.  Importantly, 
in  .NET  the  principle  of  fail-safe  defaults  is  followed  by  setting 
the  final  permission  set  to  the  intersection  of  all  policy  levels, 
whereas  in  Java  it  is  the  union. 

Typical  users  will  execute  code  found  on  untrusted  web 
sites,  so  the  Internet  default  policy  is  extremely  important  to 
protect  users  and  resources.  If  the  policy  is  too  permissive, 
the  granted  privileges  maybe  used  to  compromise  the  system. 
Java’s  default  policy  allows  an  untrusted  process  to  read  some 
environment  properties  (e.g.,  JVM  version,  Java  vendor),  stop 
its  own  threads,  listen  to  unprivileged  ports,  and  connect  to 
the  originating  host.  All  other  controlled  actions,  such  as  file 
I/O,  opening  sockets  (except  to  the  originating  host),  and  audio 
operations  are  forbidden.  The  default  Java  policy  disallows  the 
most  security-critical  operations,  but  does  not  prevent 
untrusted  applets  from  annoying  the  user.  Many  examples 
of  disruptive  applets  exist,  such  as  the  one  that  stops  and  kills 
all  current  and  future  applets  and  another  one  that  consumes 
the  CPU  (LaDue;  McGraw  and  Felten,  1999). 

The  .NET  default  permissions  are  given  by  the  intersection 
of  the  four  policy  levels  expressed  in  three  separate  files 
(AppDomains  exist  only  at  runtime).  At  runtime,  the  CLR  looks 
for  the  three  XML  policy  files  representing  the  Enterprise, 
Machine,  and  User  policy  levels.  By  default,  .NET  allows  all 
code  to  have  all  the  permissions  in  the  Enterprise  and  User 
policy  levels,  and  the  Machine  policy  level’s  granted  permis¬ 
sions  determine  the  resulting  permission  set.  The  default  pol¬ 
icy  grants  permissions  based  on  the  zone  evidence.  Local  code 
is  given  full  trust  along  with  any  strong-named  Microsoft  or 
ECMA  assemblies.  Code  from  the  local  intranet  is  granted 
many  permissions  including  printing,  code  execution,  assert¬ 
ing  granted  permissions  (see  Section  6.2),  and  reading  the 
username.  Internet  assemblies  are  given  the  Internet  permis¬ 
sion  set  which  includes  the  ability  to  connect  to  the  originat¬ 
ing  host,  execute  (itself),  open  file  dialogs,  print  through 
a  restricted  dialog  box,  and  use  its  own  clipboard.  The  trusted 
zone  will  receive  the  Internet  permission  set.  No  permissions 
are  granted  to  the  restricted  zone.  These  defaults  are  more 
consistent  with  the  principle  of  least  privilege  than  Java’s  de¬ 
faults.  But  their  strictness  may  encourage  users  to  assign  too 
many  code  sources  to  more  trusted  zones. 


5.  Associating  policies  with  code 

Since  programs  with  different  trust  levels  may  run  in  the  same 
VM,  VMs  need  secure  mechanisms  for  determining  which  policy 
should  be  enforced  for  each  access  to  a  controlled  resource.  The 


ability  to  assign  different  policies  to  different  codes  within  the 
same  VM  follows  the  principle  of  least  privilege:  every  module 
(class  or  assembly)  can  be  assigned  the  minimum  permissions 
needed  to  do  its  job,  but  this  added  flexibility  does  cost  addi¬ 
tional  complexity  and  decreased  performance.  Section  5.1  ex¬ 
plains  how  granted  permissions  are  associated  with  code. 
Section  5.2  describes  how  code  properties  determine  which  pol¬ 
icy  should  be  applied.  There  are  important  differences  of  how 
Java  and  .NET  accomplish  this.  Java’s  initial  design  was  a  simple 
model  where  code  was  either  completely  trusted  or  untrusted, 
and  all  untrusted  code  ran  with  the  same  permissions.  Later  ver¬ 
sions  of  Java  extended  this  model,  but  were  constrained  by  the 
need  to  maintain  backwards  compatibility  with  aspects  of  the 
original  design.  .NET  was  designed  with  a  richer  security  model 
in  mind  from  the  start,  so  it  incorporates  an  extensible  policy 
mechanism  in  a  consistent  way. 

5.1.  Code  permissions 

Both  Java  and  .NET  support  two  types  of  permissions:  static 
and  dynamic.  Static  permissions  are  known  and  granted  at 
load  time.  Dynamic  permissions  are  unknown  until  runtime. 

When  Java  loads  a  class,  an  instance  of  the  abstract  class, 
ClassLoader,  is  responsible  for  creating  the  association  be¬ 
tween  the  loaded  class  and  its  protection  domain.  These  static 
permissions  are  associated  with  the  class  at  runtime  through 
a  protection  domain  (PD).  Each  Java  class  will  be  mapped  to 
one  PD,  and  each  PD  encapsulates  a  set  of  permissions.  A  PD 
is  determined  based  on  the  principal  running  the  code,  the 
code’s  signers,  and  the  code’s  origin.  If  two  classes  share  the 
same  context  (principal,  signers  and  origin),  they  will  be 
assigned  to  the  same  PD,  since  their  set  of  permissions  will 
be  the  same.  Prior  to  J2SE  1.4,  permissions  were  assigned  stat¬ 
ically  at  load  time  by  default,  but  dynamic  security  permis¬ 
sions  have  been  supported  since  J2SE  1.4  (Sun  Microsystems, 
2003).  This  provides  more  flexibility,  but  increases  complexity 
and  makes  reasoning  about  security  policies  difficult. 

To  assign  static  permissions  at  load  time  in  Java,  a  class 
loader  will  assign  permissions  to  a  PD  based  on  properties  of 
the  code  and  its  source,  and  the  loaded  class  will  be  associated 
with  that  single  PD  for  the  duration  of  the  class’  lifetime  (Sun 
Microsystems,  2003;  Lindholm  and  Yellin,  1999).  Several  flaws 
have  been  reported  in  Java’s  class  loading  mechanisms,  in¬ 
cluding  8  documented  from  Sun  Microsystems,  Sun  Alert  and 
Mitre  Corporation,  Common  Vulnerabilities  (see  Table  1).  It  is 
important  to  note  that  these  static  permissions  do  not  depend 
upon  the  dynamic  permissions  as  specified  in  the  Java  policy 
files  but  rather  depends  on  the  class  loader  loading  a  class. 

.NET  uses  a  similar  approach  to  associate  permission  sets 
with  assemblies.  The  role  of  the  ClassLoader  in  Java  is  divided 
between  the  PolicyManager  and  ClassLoader  in  .NET.  The 
PolicyManager  first  resolves  the  granted  permission  set 
(LaMacchia  et  al.,  2002,  p.  173-5).  Then  the  CLR  stores  the  per¬ 
missions  in  a  cached  runtime  object  before  passing  the  code 
onto  the  ClassLoader  which  loads  the  class. 

5.2.  Code  attributes 

Both  Java  and  .NET  grant  permissions  based  on  attributes  of 
the  executing  code. 
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The  Java  VM  examines  the  CodeSource  and  Principal  and 
grants  permissions  based  on  the  values  found  in  these  objects. 
The  CodeSource  is  used  to  determine  the  location  or  origin  of 
the  code  and  signing  certificates  (if  used),  and  the  Principal 
represents  the  entity  executing  the  code.  The  associated 
PD  of  a  class  encapsulates  these  objects  along  with  the  Class 
Loader  and  static  permissions  granted  at  load  time.  To  extend 
the  default  policy  implementation,  the  Policy  class  may  need 
to  be  rewritten,  or  a  different  SecurityManager  may  need  to  be 
implemented.  It  is  questionable  if  this  level  of  extensibility  is 
actually  a  good  idea  -  it  introduces  significant  security  risks, 
but  the  benefits  in  practice  are  unclear.  Problems  with  class 
loading  were  found  in  early  Java  implementations  (Dean 
et  al.,  1996),  and  continue  to  plague  Java  today.  In  one  recent 
classloader  vulnerability  (CVE-2003-0896  in  Table  1),  arbitrary 
code  could  be  executed  by  skipping  a  call  to  a  SecurityManager 
method.  The  corresponding  code  characteristics  in  .NET  are 
known  as  evidences.  .NET’S  PolicyManager  uses  two  types  of  ev¬ 
idences,  host  evidences  and  assembly  evidences,  to  determine 
the  permissions  granted  to  an  assembly.  Assembly  evidences 
are  ignored  by  default.  Evidences  include  the  site  of  origin, 
zone  (corresponding  to  Internet  Explorer  zones),  publisher 
(X.509  certificate)  and  strong  name  (a  cryptographic  code  sig¬ 
nature).  .NET’s  design  incorporates  the  ability  to  extend  not 
only  the  permissions  that  may  be  granted,  but  also  to  add 
new  evidences  as  well.  Any  serializable  class  can  be  used  as 
evidence  (Freeman  and  Jones,  2003). 

Java  and  .NET  both  provide  complex  policy  resolution 
mechanisms  and  a  bug  in  the  policy  resolution  could  open 
a  significant  security  hole.  There  are  difficult  issues  to  con¬ 
sider  in  introducing  new  permissions  including  XML  serializa¬ 
tion,  and  declarative/imperative  testing  of  a  new  permission 
(see  Section  6,  LaMacchia  et  al.,  2002,  p.  534-44).  Although 
.NET  does  not  provide  the  same  level  of  extensibility  as  Java 
in  customizing  security  policy  enforcement,  a  developer  cre¬ 
ating  a  new  permission  must  still  be  careful  to  avoid  errors. 

5.3.  Bootstrapping 

Both  platforms  need  some  way  of  bootstrapping  to  install 
the  initial  classes  and  loading  mechanisms.  Java  1.0  used 
a  trusted  file  path  that  gave  full  trust  to  any  class  stored  on 
the  path.  Code  on  the  system  CLASSPATH  was  fully  trusted,  so 
problems  occurred  when  untrusted  code  could  be  installed 
on  the  CLASSPATH  (Hopwood,  1996).  Java  2  treats  code  found 
on  the  CLASSPATH  as  any  other  code,  but  maintains  backwards 
compatibility  by  using  the  bootclasspath  to  identify  com¬ 
pletely  trusted  code  necessary  to  bootstrap  the  class  loader. 
Hence,  the  same  risks  identified  with  installinguntrustworthy 
code  on  the  CLASSPATH  now  apply  to  the  bootclasspath.  Having 
exceptions  based  on  the  location  of  code  is  not  wise,  since  an 
attacker  who  can  modify  the  trusted  path  or  trick  a  web 
browser  into  storing  code  in  a  location  on  the  trusted  path 
will  be  able  to  execute  a  program  with  full  permissions. 

.NET  uses  full-trust  assemblies  to  break  the  recursive  load¬ 
ing  of  policies  since  all  referenced  assemblies  must  also  be 
loaded  (LaMacchia  et  al.,  2002,  p.  112).  .NET  did  not  completely 
abandon  the  notion  of  a  trusted  path,  but  it  has  added  some 
security.  .NET  uses  a  global  assembly  cache  (GAC)  where 
assemblies  in  this  cache  are  signed  and  then  shared  among 


different  assemblies.  The  GAC  acts  as  a  trusted  repository, 
similar  to  the  bootclasspath  in  that  an  assembly  within  the 
GAC  will  be  fully  trusted  (Microsoft  Corporation,  Security 
Briefs).  If  an  attacker  can  successfully  modify  an  assembly  in 
the  GAC,  then  the  attacker  may  have  full  control  of  the  ma¬ 
chine.  Sometimes  fully  trusted  assemblies  across  all  policy 
levels  are  needed;  for  example,  the  default  assemblies  used 
for  policy  resolution  that  is  fully  trusted  by  default. 

As  an  illustration,  the  .NET  default  policy  trusts  all  signed 
Microsoft  assemblies,  and  this  is  checked  by  examining  the 
strong  name  evidence  of  each  assembly.  If  all  four  policy 
levels  fully  trust  signed  Microsoft  assemblies,  then  any  as¬ 
sembly  from  Microsoft  is  fully  trusted  on  that  machine. 


6.  Enforcement 

By  allowing  partially  trusted  code  to  execute,  policy  enforce¬ 
ment  becomes  more  complicated.  Policy  enforcement  is 
chiefly  done  at  runtime  by  the  virtual  machine.  Unlike  Java, 
.NET  can  perform  some  policy  enforcement  statically  by 
allowing  the  programmer  to  specify  static  or  dynamic  policy 
enforcement.  Declarative  security  permissions  are  statically 
known  and  contained  within  the  assembly  manifest.  Impera¬ 
tive  security  permissions  are  compiled  to  MSIL  and  evaluated 
at  runtime.  The  declarative  permissions  can  be  class-wide  or 
method-wide  and  can  be  used  for  some  actions  that  cannot 
be  expressed  using  imperative  permissions.  When  runtime  in¬ 
formation  is  needed  to  evaluate  a  request  (e.g.,  a  filename), 
imperative  permissions  must  be  used. 

Runtime  enforcement  mechanisms  share  many  similari¬ 
ties  across  the  two  platforms.  Both  platforms  implement  a  ref¬ 
erence  monitor  designed  to  follow  the  principle  of  complete 
mediation  by  checking  the  necessary  permissions  before 
allowing  any  sensitive  operation.  In  Java,  the  SecurityManager 
checks  code  permissions.  Programmers  can  implement  Secur¬ 
ityManager  subtypes  to  customize  security  checking,  and  pro¬ 
grams  with  sufficient  permission  can  change  the  security 
manager.  This  makes  it  especially  easy  to  exploit  a  type  safety 
break  in  Java,  since  the  security  manager  can  be  set  to  null  to 
turn  off  all  access  control.  .NET’s  design  does  not  allow  pro¬ 
grammers  to  implement  their  own  SecurityManager  class, 
but  the  reduced  flexibility  provides  stronger  security. 

6.1.  Checking  permissions 

When  a  Java  program  attempts  a  restricted  operation,  the 
called  Java  API  method  first  calls  the  SecurityManager  ’  s  appro¬ 
priate  checkPermission  method  which  calls  the  AccessControl- 
ler  to  determine  if  the  necessary  permission  is  granted.  When 
deciding  to  grant  a  permission  to  execute  a  requested  action, 
the  AccessController  checks  that  the  current  executing  thread 
has  the  needed  permission. 

The  12  API  bugs  in  Table  1  illustrate  the  difficulty  in  imple¬ 
menting  permission  checks  correctly.  Many  of  these  vulnera¬ 
bilities  involve  an  API  method  that  allows  access  to 
a  protected  resource  without  the  necessary  security  checks. 
CVE-2000-0676  and  CVE-2000-0711  both  bypass  calls  using 
SecurityManager  by  exploiting  the  java.  net.  ServerSocket 
and  netscape  .net  .URLInputStream  classes.  Another  flaw, 
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CVE-2000-0563,  used  browser  redirection  to  gain  sensitive  data 
in  j  ava .  net .  URLConnect  ion.  Two  vulnerabilities,  CVE-2002-0866 
and  CVE-2002-1260,  involve  bugs  in  the  Java  Database  Connec¬ 
tivity  (JDBC)  classes  with  the  former  allowing  an  attacker  to  ex¬ 
ecute  any  local  Dynamic  Link  Library  (DLL)  through  a  JDBC 
constructor  and  the  latter  allowing  access  to  a  database 
through  a  JDBC  API  call.  CVE-2002-1290  and  CVE-2002-1293 
were  bugs  in  Microsoft’s  JVM  that  exposed  interfaces  to  the 
INativeServices  and  CabCracker  classes  allowing  access  to  the 
clipboard  or  local  file  system,  respectively.  CVE-2002-0865, 
CVE-2002-0979  and  CVE-2002-1288  exposed  various  resources 
including  XML  interfaces,  logging,  and  directory  information. 
The  last  API  bugs,  CVE-2005-3905  and  CVE-2005-3906,  are 
both  related  to  errors  in  the  Reflection  API  enabling  an  attacker 
to  read  and  write  local  files  or  execute  applications  on  the  local 
machine. 

Java’s  AccessController  must  not  only  verify  that  the  cur¬ 
rent  stack  frame  has  the  required  permission,  but  also  that 
the  calling  stack  frames  do.  In  this  way,  previously  called 
methods  cannot  gain  privileges  by  calling  higher  privileged 
code.  Since  every  method  belongs  to  a  class  and  a  class  to 
a  PD,  each  stack  frame’s  permissions  are  checked  through 
the  associated  PD  in  addition  to  any  dynamic  permissions 
granted  by  the  policy.  If  any  stack  frame  has  not  been  granted 
the  permission  for  the  requested  access,  then  the  request  will 
be  denied  by  throwing  an  exception.  The  AccessController  ac¬ 
complishes  permission  checks  by  calling  a  method  to  indi¬ 
rectly  return  an  object  encapsulating  the  current  PDs  on  the 
stack  (i.e.,  current  context)  and  then  checking  those  PDs’  per¬ 
missions.  The  act  of  gathering  the  current  permissions  from 
each  stack  frame  is  called  a  stack  walk. 

.NET  performs  a  similar  stack  walk  with  Frame  objects  rep¬ 
resenting  the  call  frames  on  the  stack.  To  support  multiple 
languages  (including  type  unsafe  languages  like  C++),  the 
stack  has  frames  that  are  managed  and  unmanaged.  The  man¬ 
aged  frames  are  frames  that  are  verified  for  type  safety  while 
the  unmanaged  frames  have  no  safety  guarantees.  As  the 
stack  is  traversed,  the  managed  code’s  permissions  are 
checked  with  a  security  object  contained  in  each  JIT-compiled 
method  on  the  stack  (Stutz  et  al.,  2003). 

6.2.  Modifying  the  stack  walk 

In  both  platforms,  programmers  can  modify  the  stack  walk. 
This  should  be  done  to  enforce  the  principle  of  least  privilege 
by  explicitly  denying  permissions  to  called  methods,  but  pro¬ 
grammers  must  be  careful  to  not  allow  more  permissions 
when  changing  stack  walk  behavior. 

A  Java  program  can  modify  the  stack  walk  to  deny  certain 
permissions  past  a  specific  stack  frame  or  to  simply  stop  check¬ 
ing  permissions  at  a  specific  point.  If  a  method  invokes  doPri- 
vileged  (PrivilegedAction) ,  the  stack  walk  will  not  look  at  any 
frames  further  up  the  call  stack.  Attacks  have  occurred  where 
the  caller  gains  access  to  some  protected  resource  by  calling 
code  that  has  higher  privileges  which  indirectly  provides  ac¬ 
cess  to  that  resource  (for  example,  CVE-2002-1288).  To  deny 
permissions  to  a  method  in  Java,  a  method  can  invoke  doPrivi- 
leged  (PrivilegedAction,  AccessControlContext) .  This  creates 
a  new  context  that  is  the  same  as  the  stack’s  current  execution 
context  without  the  denied  permissions.  The  stack  walk  will 


then  use  this  context  to  check  permissions.  However,  using 
doPr  ivileged  can  introduce  access  modifier  issues  when  imple¬ 
mented  with  an  inner  class  (Gong  et  al.,  2003;  Sun  Microsys¬ 
tems,  Permissions). 

.NET  has  extended  Java’s  stack  walk  design  with  the  Per 
mission  methods  PermitOnly( ),  Assert( ),  and  Deny( ).  A  stack 
walk  is  done  when  a  demand( )  call  is  made,  similar  to  Java’s 
checkPermission( ).  .NET  provides  slightly  better  interfaces 
for  the  programmer  to  alter  the  stack  walk  since  many  of 
the  mechanisms  involve  only  one  method  call  after  construct¬ 
ing  the  specified  permissions.  Calling  the  PermitOnlyC ) 
method  means  a  stack  walk  will  continue  only  if  the  permis¬ 
sion  is  granted.  After  a  Deny( )  call,  if  any  of  the  specified  per¬ 
missions  are  requested  an  exception  is  thrown  to  terminate 
the  stack  walk.  Assert  ( )  terminates  the  stack  walk  success¬ 
fully  if  the  current  stack  frame  has  the  asserted  permission. 

Although  stack  inspection  is  complex  in  both  models, 
.NET’S  added  flexibility  using  these  new  Permission  methods 
can  be  used  to  help  programmers  improve  security  by  writing 
code  that  does  not  expose  protected  resources  unnecessarily. 


7.  Psychological  acceptability 

Saltzer  and  Shroeder  (1973)  identified  “Psychological  Accept¬ 
ability”  as  their  final  security  principle,  and  emphasized  the 
importance  of  protection  mechanisms  fitting  the  user’s  pro¬ 
tection  goals.  This  principle  is  often  overlooked  (Clear,  2002), 
and  challenging  to  follow  even  when  it  is  considered,  and 
Java  and  .NET  are  not  exceptions. 

Both  VMs  have  extensible  policies,  but  their  policies  are  still 
difficult  for  typical  users  to  configure  and  understand.  Since 
the  permissions  do  not  clearly  show  what  resources  they 
may  protect,  the  user  may  grant  access  to  resources  uninten¬ 
tionally.  Even  if  a  machine  is  properly  configured,  a  user  may 
be  faced  with  a  situation  where  the  policy  is  violated,  a  security 
exception  is  raised,  and  the  application  terminates.  In  order  to 
get  the  application  to  run,  the  user  needs  to  understand  what 
security  violation  happened,  how  to  configure  the  machine  to 
permit  the  security  sensitive  operation,  and  what  security 
implications  are  there  in  granting  the  requested  operation.  If 
a  certificate  has  been  revoked  or  expired,  exceptions  will  occur 
that  a  normal  user  will  have  trouble  in  understanding.  Most 
likely,  the  user  may  grant  full  trust  in  both  of  these  situations 
if  the  application  is  important  enough.  When  a  security  excep¬ 
tion  or  other  similar  exception  occurs,  more  guidance  is 
needed,  so  the  user  can  take  the  correct  action. 

In  Sun’s  Java  Development  Kit  (JDK)  1.0  the  security  model 
treated  all  applets  as  untrusted  and  confined  them  to  a  limited, 
albeit  inflexible,  environment  known  as  the  Java  sandbox.  JDK 
1.1  introduced  signed  applets,  so  the  user  could  choose  to 
execute  the  applet  with  full  permissions  based  on  the  entity 
associated  with  the  applet’s  signature.  Just  prior  to  the  release 
of  JDK  1.2,  Microsoft  and  Netscape  introduced  a  more  flexible 
security  model,  the  Java  model  in  this  paper,  that  allowed 
users  to  execute  partially  untrusted  code  with  limited  permis¬ 
sions.  Unfortunately,  Netscape’s  model  (Netscape  Capabilities 
Model)  had  drawbacks  to  its  initial  implementation.  In  the 
Netscape  Capabilities  Model,  whenever  an  applet  needs  per¬ 
mission  to  access  a  protected  resource,  the  user  is  presented 
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with  a  dialog  box.  Once  the  user  grants  the  permission,  the  ap¬ 
plication  can  perform  the  requested  operation  until  the  user 
terminates  Netscape  Communicator  (Netscape  Communica¬ 
tions  Corporation).  Although  the  user  can  click  a  button  for 
further  details,  another  dialog  box  is  presented  to  help.  If  the 
user  runs  the  applet  again  after  restarting  Netscape,  then 
he/she  again  goes  through  the  same  process  with  the  alterna¬ 
tive  options  of  denying  permission,  or  he/she  can  perma¬ 
nently  grant  the  requested  permissions  to  the  applet. 
Bombarding  the  user  with  dialog  boxes  that  require  a  quick  se¬ 
curity  decision  to  be  made  in  order  for  execution  to  continue  is 
a  bad  idea  (McGraw  and  Felten,  1999).  Luckily  this  behavior 
has  changed  in  current  Java  security  models,  and  security  ex¬ 
ceptions  do  not  encourage  the  user  to  make  a  hasty  decision. 

Another  problem  area  is  the  default  permissions.  The  de¬ 
signers  took  steps  to  protect  certain  API  functions,  but  it  can 
be  difficult  to  determine  which  permissions  to  grant  by  looking 
only  at  the  permission  (and  not  the  resource).  With  a  higher 
granularity  of  protection  in  some  permissions,  .NET  helps 
the  user  to  choose  safe  and  usable  permissions.  For  example, 
the  clipboard  permission  is  not  a  binary  decision  where  the 
code  has  all  or  nothing  access  to  a  resource.  Instead,  code 
can  have  unlimited  write  access  to  the  clipboard,  but  it  cannot 
have  read  access.  Since  this  permission  model  allows  finer- 
grained  protection,  this  allows  the  user  to  safely  execute 
code  while  not  having  to  grant  full  read/write  access  to  the 
clipboard.  Since  a  user  only  wants  to  protect  his/her  private 
data,  this  model  conforms  to  the  user’s  understanding.  An¬ 
other  example  is  the  window  permissions  that  protect  the 
user  from  fake  dialog  boxes  and  phishing  attacks  by  enforcing 
restrictions  on  specific  window  components  (e.g.,  Forms, 
DataGrids,  and  Cursors)  (Microsoft  Visual  Studio).  Users  inter¬ 
act  with  GUI  programs  through  these  types  of  window  compo¬ 
nents,  so  the  user  is  better  able  to  evaluate  implications  on 
security  by  granting  access  to  these  familiar  resources. 


8.  Conclusion 

Java  and  .NET  have  similar  security  goals  and  mechanisms. 
.NET’s  design  benefited  from  past  experience  with  Java.  Exam¬ 
ples  of  this  cleaner  design  include  the  MSIL  instruction  set, 
code  access  security  evidences,  and  the  policy  configuration. 
.NET  has  been  able  to  shield  the  developer  from  some  of  the 
underlying  complexity  through  their  new  architecture. 

Where  Java  evolved  from  an  initial  platform  with  limited  se¬ 
curity  capabilities,  .NET  incorporated  more  security  capability 
into  its  original  design.  With  age  and  new  features,  much  of 
the  legacy  code  of  Java  still  remains  forbackwards  compatibility 
including  the  possibility  of  a  null  Security-Manager,  and  the 
absolute  trust  of  classes  on  the  bootclasspath.  However,  Java  is 
applying  a  learned  lesson  as  it  makes  the  verifier  simpler  (at 
a  cost  of  compatibility).  Hence,  in  several  areas  .NET  has  security 
advantages  over  Java  because  of  its  simpler  and  cleaner  design. 

Most  of  the  lessons  to  learn  from  Java’s  vulnerabilities  echo 
Saltzer  and  Schroeder’s  classic  principles,  especially  economy 
of  mechanism,  least  privilege  and  fail-safe  defaults.  Of  course, 
Java’s  designers  were  aware  of  these  principles,  even  though  in 
hindsight  it  seems  clear  there  were  occasions  where  they  could 
(and  should)  have  been  followed  more  closely  than  they  were. 


Some  areas  of  design  present  conflicts  between  security  and 
other  design  goals  including  fail-safe  defaults  vs.  usability 
and  least  privilege  vs.  usability  and  complexity.  For  example, 
the  initial  stack  walk  introduced  in  Java  has  evolved  to 
a  more  complex  stack  walk  in  both  architectures  to  enable  de¬ 
velopers  limit  privileges.  In  addition,  both  platforms  default 
policies  could  be  more  restrictive  to  improve  security,  but  re¬ 
strictive  policies  hinder  the  execution  of  programs.  .NET’s 
use  of  multi-level  policies  with  multiple  principals  provides 
another  example  of  showing  the  principles  of  least  privilege 
and  fail-safe  defaults  in  contention  with  usability  and  com¬ 
plexity.  Several  of  the  specific  complexities  that  proved  to  be 
problematic  in  Java  have  been  avoided  in  the  .NET  design, 
although  .NET  introduced  new  complexities  of  its  own.  Despite 
.NET’s  design  certainly  not  being  perfect,  it  does  provide  en¬ 
couraging  evidence  that  system  designers  can  learn  from 
past  security  vulnerabilities  and  develop  more  secure  systems. 
We  have  no  doubts,  however,  that  system  designers  will  con¬ 
tinue  to  relearn  these  principles  for  many  years  to  come. 
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Appendix  A. 

.NET  security  issues 

There  have  been  8  security  issues  identified  in  the  .NET  frame¬ 
work  listed  in  Microsoft’s  Knowledge  Base  (Farkas),  only  one 
(KB327523)  of  which  appears  to  be  exploitable.  Because  this 
problem  appears  to  be  in  an  ASP.NET  HTTP  module’s  parsing 
of  an  HTML  request  (also  included  in  the  CVE  database  as 
CAN-2004-0847)  and  not  in  the  .NET  framework  (Baier),  we 
do  not  count  this  as  a  .NET  platform  security  vulnerability. 
However,  this  is  still  a  significant  security  vulnerability  that 
could  be  exploited  by  an  attacker  to  obtain  arbitrary  .aspx  files 
from  an  ASP.NET  web  server.  Notably,  similar  issues  (CAN- 
2002-1258,  CAN-2002-1295,  CAN-2002-1291,  CVE-2002-1257, 
CAN-2002-1286)  appeared  in  parsing  URLs  and  HTML  content 
in  Microsoft’s  Java  implementation  in  the  past  (Clear,  2002) 
(these  are  not  included  in  the  count  of  Java  security  vulnera¬ 
bilities  either). 

Of  the  remaining  seven  issues,  two  (KB836989,  KB828295) 
are  not  security  vulnerabilities,  but  false  positives  in  which 
a  security  exception  prevents  a  safe  operation  from  proceed¬ 
ing.  Two  more  bugs  (KB324488,  KB321562),  also  false  posi¬ 
tives,  do  not  throw  a  security  exception,  but  still  prevent 
a  normally  safe  operation.  Two  of  the  remaining  bugs  are 
in  system  classes  that  were  implemented  incorrectly.  The 
first  (KB327132)  ignores  a  parameter  for  Passport  authentica¬ 
tion  in  ASP.NET  incorrectly  authenticating  users  without  re¬ 
quiring  a  PIN.  The  other  (KB839289)  is  a  GC  heap  corruption 
exhibited  in  a  cryptography  provider  class  when  the  class 
constructor  is  called  during  garbage  collection.  The  last 
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Microsoft  knowledge  base  bug  (KB323683)  is  an  optimization 
fix  for  NLTM  authentication  that  does  not  require  re-authen- 
tication  on  multiple  calls  over  the  same  connection.  Although 
these  are  legitimate  security  issues,  none  of  them  are  at  the 
level  of  the  .NET  platform  itself. 
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